A process executes a set of instructions. Executable instructions are stored in files on a storage disk. Before a process executes, its executable instructions must be loaded from a file into physical memory. Files are typically organized into any number of uniformly-sized logical divisions called pages. Hence, a page constitutes the indivisible unit of manageable data managed by a memory management unit.
Because physical memory has historically been a limited resource, the concept of virtual memory is used to extend physical memory by way of strategic use of storage disks. For example, a primary effect of virtual memory is the notion of presenting an executing process or application with a contiguous virtual memory address space when in fact it is physically fragmented in physical memory and perhaps on a storage disk. In instances when the memory need for a process does in fact overflow from physical memory onto storage disks, one consideration is determining whether a particular page should be maintained in physical memory or on a storage disk. Because physical memory exhibits a more favorable access time than a storage disk, a virtual memory scheme may maintain more frequently accessed pages in physical memory. As such, the storage disk can be thought of as a backing store for physical memory because it also acts to maintain the less frequently-accessed pages of a process.
In view of this fragmented aspect of physical addressing, memory management for an executing process is frequently managed using a granularity of a page of data. For example, the virtual memory address space for a particular process may exhibit a number of mappings to the pages loaded in physical memory that are relevant to the execution of the process. Each mapping is associated with an access privilege. For example, a read-only access privilege only permits the process to read from but not modify the mapped page. On the other hand, a read-write access privilege permits the process to both read from and modify the mapped page.
Page-scale granularity has been crucial in the development of process creation routines. Traditionally, when a new process is created, a “fork” operation makes a copy of a currently executing parent process. As a result, copies of pages privately mapped to by the parent process are then duplicated in physical memory for mapping to by the newly-created child process.
The copy-on-write (COW) procedure was then developed as a solution to bypass the intensive page copy creation involved in the traditional “fork” operation. Instead of creating a new set of identical pages, the COW procedure merely maps to the existing pages from the virtual memory address space of the child process. In a sense, the parent and child processes are now sharing pages. Further, the processing required to create per-page copies of what the parent process maps to is not wasted if the newly-created child process subsequently executes a new and different program that requires a new set of pages to be loaded into physical memory.
Because pages are effectively shared between processes after a copy-on-write procedure, the mappings from both the parent and child process virtual memory address spaces to the commonly-shared pages in physical memory are defined by read-only access privileges. As such, measures are taken when either the parent or child process attempts to write to a shared page. At the outset, if the parent has a read-write access privilege, then the private mapping from the parent's virtual memory address space must have that read-write access privilege removed, which requires a communication with each processor in the computer system. Further, to remedy the issue of data ownership in light of an attempt to write to data that was until this point effectively shared, a copy of the page is created. Because the copy of the page is intended to be write-eligible, the copy of the page is then privately mapped with a read-write access privilege to the virtual memory address space of the writing process.